An ever-increasing number of e-commerce providers or e-businesses rely on application server technology as the lifeblood of their business. Application servers form a proven foundation for supporting e-commerce applications, providing the presentation, business and information-access logic, security and management services, and underlying infrastructure required for highly scalable and mission-critical software applications. Increasingly, the demands of today's modern businesses require support for a new breed of Web and wireless applications, helping to meet the needs of increasingly sophisticated customers.
One such application server, WebLogic Server, from BEA Systems, Inc. San Jose, Calif., is based on an implementation of the Java 2 Enterprise Edition (J2EE) specification. WebLogic Server is used as the backbone for many of today's most sophisticated e-business applications, playing an integral role in a tightly integrated, comprehensive infrastructure that delivers commerce, personalization, campaign management, enterprise integration, workflow management, and business-to-business collaboration. From Web and wireless clients to Windows, Unix, and mainframe servers, WebLogic Server manages all of the underlying complexities of a business' e-commerce applications, allowing the organization to focus instead on delivering new and innovative products and services.
A typical application server, including WebLogic Server, supports a variety of clients, including Web browsers, and wireless devices. On the server side, WebLogic Server supports leading Unix, Linux, Windows, and mainframe operating systems. On the back-end, WebLogic Server integrates with relational databases, messages queues, and legacy systems. WebLogic Server provides support for features such as Servlets, Java Server Pages (JSPs), Enterprise JavaBeans (EJBs), Java Messaging Service (JMS), to provide access to standard network protocols, database, and messaging systems. When developing applications, developers can create, assemble, and deploy components that use these services.
In a typical deployment, WebLogic Server also includes a Web server for hosting static content and dynamic J2EE Web applications. J2EE Web applications typically include a collection of HTML/XML pages, Java Server Pages, Servlets, Java classes, applets, images, multimedia files, and other file types. WebLogic Server may also be integrated with other Web servers such as Apache, Microsoft IIS, or Netscape Web servers. Web components usually provide the presentation logic for browser-based or wireless applications, while EJB components encapsulate business objects and processes.
Many Web servers, such as those discussed above, were originally designed as simple engines for transmitting physical files from a host machine or server to the user's client or Web browser. This file-oriented legacy still remains, although many Web servers such as Apache allow files to be sent to the browser unmodified or instead parsed by content handlers to transform before sending them on to the browser. For example, when Apache receives a request, the URI is passed through any URI translation handlers that may be installed, transforming it into a file path. Next, Apache attempts to divide the file path into two parts: a “filename” part which usually (but not always) corresponds to a physical file on the host's file system, and an “additional path information” part corresponding to additional stuff that follows the filename. Apache divides the path using a very simple-minded algorithm. It steps through the path components from left to right until it finds something that doesn't correspond to a directory on the host machine. The part of the path up to and including this component becomes the filename, and everything that's left over becomes the additional path information.
Many currently available application servers, including the WebLogic Server product, employ pattern matching rules defined by the corresponding J2EE specification. However, the J2EE pattern matching is very limiting. It allows only three kind of patterns:    1. path based and exact, for example: “/foo/bar”;    2. path based with wild-card, for example: “/foo/bar/*”; and,    3. extension based, for example: “*.blah”.
The following scenario gives an example of the j2ee pattern matching limitation: Suppose one has *.blah mapped to a given servlet, and a request comes in to http://foo.com/abcd/bar.blah/efg, then the server will not be able to resolve the request correctly. It will however be able to resolve http://foo.com/abcd/bar.blah correctly. Conversely, Apache can properly interpret this extension (seeing the request as meaning http://foo.com/bar.blah, together with an /efg extension modifier).
This difference in interpretation leads to unpredictable results, particularly when legacy systems are included in the network. Sophisticated server customers (i.e. application developers) have expressed an interest in an application server or Web server product that provides a more powerful approach to pattern matching, including (although not necessarily limited to) Apache-style pattern matching. This is a valuable feature not only for migrating legacy Web sites, but also because the e.g. Apache scheme is more flexible in some situations. Accordingly, what is needed is a mechanism for providing application and Web servers with the ability to specify or customize their file and file type pattern matching features to suit the particular needs of the Web application environment.